home *** CD-ROM | disk | FTP | other *** search
/ IRIX Base Documentation 2002 November / SGI IRIX Base Documentation 2002 November.iso / usr / share / catman / p_man / cat3 / librw / RWCLIPstreambuf.z / RWCLIPstreambuf
Encoding:
Text File  |  2002-10-03  |  10.0 KB  |  199 lines

  1.  
  2.  
  3.  
  4. RRRRWWWWCCCCLLLLIIIIPPPPssssttttrrrreeeeaaaammmmbbbbuuuuffff((((3333CCCC++++++++))))                                    RRRRWWWWCCCCLLLLIIIIPPPPssssttttrrrreeeeaaaammmmbbbbuuuuffff((((3333CCCC++++++++))))
  5.  
  6.  
  7.  
  8. NNNNaaaammmmeeee
  9.      RWCLIPstreambuf - Rogue Wave library class
  10.  
  11. SSSSyyyynnnnooooppppssssiiiissss
  12.               #include <rw/winstrea.h>
  13.  
  14.  
  15.  
  16.               #include <iostream.h>
  17.           iostream str( new RWCLIPstreambuf() );
  18.  
  19.  
  20.  
  21.  
  22. DDDDeeeessssccccrrrriiiippppttttiiiioooonnnn
  23.      Class RRRRWWWWCCCCLLLLIIIIPPPPssssttttrrrreeeeaaaammmmbbbbuuuuffff is a specialized ssssttttrrrreeeeaaaammmmbbbbuuuuffff that gets and puts
  24.      sequences of characters to Microsoft Windows global memory.  It can be
  25.      used to exchange data through Windows clipboard facility.  The class has
  26.      two modes of operation: dynamic and static.  In dynamic mode, memory is
  27.      allocated and reallocated as needed.  If too many characters are inserted
  28.      into the internal buffer for its present size, then it will be resized
  29.      and old characters copied over into any new memory as necessary.  This is
  30.      transparent to the user.  It is expected that this mode would be used
  31.      primarily for "insertions," iiii....eeee...., clipboard "cuts" and "copies."  In
  32.      static mode, the buffer streambuf is constructed from a specific piece of
  33.      memory.  No reallocations will be done.  It is expected that this mode
  34.      would be used primarily for "extractions," iiii....eeee...., clipboard "pastes."  In
  35.      dynamic mode, the RRRRWWWWCCCCLLLLIIIIPPPPssssttttrrrreeeeaaaammmmbbbbuuuuffff "owns" any allocated memory until the
  36.      member function ssssttttrrrr(((()))) is called, which "freezes" the buffer and returns
  37.      an unlocked Windows handle to it.  The effect of any further insertions
  38.      is undefined.  Until ssssttttrrrr(((()))) has been called, it is the responsibility of
  39.      the RRRRWWWWCCCCLLLLIIIIPPPPssssttttrrrreeeeaaaammmmbbbbuuuuffff destructor to free any allocated memory.  After the
  40.      call to ssssttttrrrr(((()))), it becomes the user's responsibility.  In static mode, the
  41.      user has the responsibility for freeing the memory handle.  However,
  42.      because the constructor locks and dereferences the handle, you should not
  43.      free the memory until either the destructor or ssssttttrrrr(((()))) has been called,
  44.      either of which will unlock the handle.
  45.  
  46. PPPPeeeerrrrssssiiiisssstttteeeennnncccceeee
  47.      None
  48.  
  49. EEEExxxxaaaammmmpppplllleeee
  50.               //Instructions:  compile as a Windows program.
  51.           //Run this program, then using your favorite text editor or word
  52.           //processor, select paste and see the result!
  53.           #include <rw/winstrea.h>
  54.           #include <stdlib.h>
  55.           #include <iostream.h>
  56.           #include <windows.h>
  57.           void postToClipboard(HWND owner);
  58.           main()
  59.           {
  60.  
  61.  
  62.  
  63.                                                                         PPPPaaaaggggeeee 1111
  64.  
  65.  
  66.  
  67.  
  68.  
  69.  
  70. RRRRWWWWCCCCLLLLIIIIPPPPssssttttrrrreeeeaaaammmmbbbbuuuuffff((((3333CCCC++++++++))))                                    RRRRWWWWCCCCLLLLIIIIPPPPssssttttrrrreeeeaaaammmmbbbbuuuuffff((((3333CCCC++++++++))))
  71.  
  72.  
  73.  
  74.              postToClipboard(NULL);
  75.              return 0;
  76.           }
  77.           // PASS YOUR WINDOW HANDLE TO THIS FUNCTION THEN PASS YOUR VALUES
  78.           // TO THE CLIPBOARD USING ostr.
  79.           void postToClipboard(HWND owner)
  80.           {
  81.              //Build the clipstream buffer on the heap
  82.              RWCLIPstreambuf* buf = new
  83.              RWCLIPstreambuf();
  84.              ostream ostr(buf);
  85.              double d = 12.34;
  86.              ostr << "Some text to be exchanged through the clipboard.0;
  87.              ostr << "Might as well add a double: " << d << endl;
  88.              ostr.put(' ');        // Include the terminating null
  89.              // Lock the streambuf, get its handle:
  90.              HANDLE hMem = buf->str();
  91.              OpenClipboard(owner);
  92.              EmptyClipboard();
  93.              SetClipboardData(CF_TEXT, hMem);
  94.              CloseClipboard();
  95.  
  96.              // Don't delete the buffer!.  Windows is now responsible for it.
  97.           }
  98.  
  99.  
  100.      The owner of the clipboard is passed in as parameter "oooowwwwnnnneeeerrrr".  A
  101.      conventional oooossssttttrrrreeeeaaaammmm is created, except that it uses an RRRRWWWWCCCCLLLLIIIIPPPPssssttttrrrreeeeaaaammmmbbbbuuuuffff
  102.      as its associated ssssttttrrrreeeeaaaammmmbbbbuuuuffff.  It can be used much like any other oooossssttttrrrreeeeaaaammmm,
  103.      such as ccccoooouuuutttt, except that characters will be inserted into Windows global
  104.      memory.  Some text and a double is inserted into the oooossssttttrrrreeeeaaaammmm.  Finally,
  105.      member function ssssttttrrrr(((()))) is called which returns a Windows HHHHAAAANNNNDDDDLLLLEEEE.  The
  106.      clipboard is then opened, emptied, and the new data put into it with
  107.      format CCCCFFFF____TTTTEEEEXXXXTTTT which, in this case, is appropriate because a simple
  108.      oooossssttttrrrreeeeaaaammmm was used to format the output.  If a specializing virtual streams
  109.      class such as RRRRWWWWbbbboooossssttttrrrreeeeaaaammmm or RRRRWWWWppppoooossssttttrrrreeeeaaaammmm had been used instead, the format
  110.      is not so simple.  In this case, the user might want to register his or
  111.      her own format, using the Windows function RRRReeeeggggiiiisssstttteeeerrrrCCCClllliiiippppbbbbooooaaaarrrrddddFFFFoooorrrrmmmmaaaatttt(((()))).
  112.  
  113. PPPPuuuubbbblllliiiicccc CCCCoooonnnnssssttttrrrruuuuccccttttoooorrrrssss
  114.               RRRRWWWWCCCCLLLLIIIIPPPPssssttttrrrreeeeaaaammmmbbbbuuuuffff();
  115.  
  116.  
  117.      Constructs an empty RRRRWWWWCCCCLLLLIIIIPPPPssssttttrrrreeeeaaaammmmbbbbuuuuffff in dynamic mode.  The results can be
  118.      used anywhere any other ssssttttrrrreeeeaaaammmmbbbbuuuuffff can be used.  Memory to accomodate new
  119.      characters will be allocated as needed.
  120.  
  121.               RRRRWWWWCCCCLLLLIIIIPPPPssssttttrrrreeeeaaaammmmbbbbuuuuffff(HANDLE hMem);
  122.  
  123.  
  124.      Constructs an RRRRWWWWCCCCLLLLIIIIPPPPssssttttrrrreeeeaaaammmmbbbbuuuuffff in static mode, using the memory block with
  125.      global handle hhhhMMMMeeeemmmm.  The effect of ggggeeeettttssss and ppppuuuuttttssss beyond the size of this
  126.  
  127.  
  128.  
  129.                                                                         PPPPaaaaggggeeee 2222
  130.  
  131.  
  132.  
  133.  
  134.  
  135.  
  136. RRRRWWWWCCCCLLLLIIIIPPPPssssttttrrrreeeeaaaammmmbbbbuuuuffff((((3333CCCC++++++++))))                                    RRRRWWWWCCCCLLLLIIIIPPPPssssttttrrrreeeeaaaammmmbbbbuuuuffff((((3333CCCC++++++++))))
  137.  
  138.  
  139.  
  140.      memory block is unspecified.
  141.  
  142. PPPPuuuubbbblllliiiicccc DDDDeeeessssttttrrrruuuuccccttttoooorrrr
  143.               ~RRRRWWWWCCCCLLLLIIIIPPPPssssttttrrrreeeeaaaammmmbbbbuuuuffff();
  144.  
  145.  
  146.      If member function ssssttttrrrr(((()))) has not been called, the destructor unlocks the
  147.      handle and, if in dynamic mode, also frees it.
  148.  
  149. PPPPuuuubbbblllliiiicccc MMMMeeeemmmmbbbbeeeerrrr FFFFuuuunnnnccccttttiiiioooonnnnssss
  150.  
  151.  
  152.  
  153.      Because RRRRWWWWCCCCLLLLIIIIPPPPssssttttrrrreeeeaaaammmmbbbbuuuuffff inherits from ssssttttrrrreeeeaaaammmmbbbbuuuuffff, any of the latter's
  154.      member functions can be used.  Furthermore, RRRRWWWWCCCCLLLLIIIIPPPPssssttttrrrreeeeaaaammmmbbbbuuuuffff has been
  155.      designed to be analogous to ssssttttrrrrssssttttrrrreeeeaaaammmmbbbbuuuuffff.  However, note that the return
  156.      type of ssssttttrrrr(((()))) is a HHHHAAAANNNNDDDDLLLLEEEE, rather than a cccchhhhaaaarrrr****.
  157.  
  158.               HANDLE
  159.           ssssttttrrrr();
  160.  
  161.  
  162.      Returns an (unlocked) HHHHAAAANNNNDDDDLLLLEEEE to the global memory being used.  The
  163.      RRRRWWWWCCCCLLLLIIIIPPPPssssttttrrrreeeeaaaammmmbbbbuuuuffff should now be regarded as "frozen":  the effect of
  164.      inserting any more characters is undefined.  If the RRRRWWWWCCCCLLLLIIIIPPPPssssttttrrrreeeeaaaammmmbbbbuuuuffff was
  165.      constructed in dynamic mode, and nothing has been inserted, then the
  166.      returned HHHHAAAANNNNDDDDLLLLEEEE may be NNNNUUUULLLLLLLL.  If it was constructed in static mode, then
  167.      the returned handle will be the handle used to construct the
  168.      RRRRWWWWCCCCLLLLIIIIPPPPssssttttrrrreeeeaaaammmmbbbbuuuuffff.
  169.  
  170.  
  171.  
  172.  
  173.  
  174.  
  175.  
  176.  
  177.  
  178.  
  179.  
  180.  
  181.  
  182.  
  183.  
  184.  
  185.  
  186.  
  187.  
  188.  
  189.  
  190.  
  191.  
  192.  
  193.  
  194.  
  195.                                                                         PPPPaaaaggggeeee 3333
  196.  
  197.  
  198.  
  199.